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The present invention relates to the field of remote electronic transaction systems, and more 
particularly to a method for improving the reliability of message transmission between wireless 
devices and a terminal. 



Introduction 

The following description incorporates herein by reference United States Patent Application 
No. 09/559,278 filed April 27, 2000 and the terms and expressions not defined in the 
following document are assumed defined in said incorporated reference. 

This document covers the idea of Pending Persistent Reversal (PPR). PPR deals with 
extending a server-side state machine out to stateless micro-browser based devices. PPR is 
not considered a specific financial transaction. It is the combination of using MTCP reversal 
requests and negotiating a sequencing algorithm with the mobile device. The goals of PPR are 
th following: 

• Detect duplicate messages from a mobile device. 

• Detect a possible undelivered message from a mobile device. 

• Implement MTCP reversals to avoid out of balance situations at the bank. 

PPR Specifics 

For each request received by the application server business logic, the application server 
processes the request. Once the request has been processed successfully, the request is 
given a status of Pending Persistent Reversal. This status is necessary, as the application 
server cannot determine if the mobile device has received the response until the next 
request is received. Based on the sequence number of the next incoming request, the 
business logic will either set the status of the previous transaction to completed, or the 
business logic will reverse the previous transaction. 

Control of the sequence number is handled by the business logic within the application server. 
The business logic attaches the next sequence number expected by the mobile device on the 
outgoing response message. The payment application kept at the web tier keeps this 
sequence number and downloads it as a hidden field on the next set of user interface cards. 
The next request received by the mobile device can be one of three possibilities: the proper 
sequence number is sent, the previous sequence number is sent with a duplicate of the 
pr vious request, or the previous sequence number is sent with a different request. 
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Scenario One 

1. A request is sent from the WAP devic with sequence number 1 and is received by the 
payment application. 

2. The payment application forwards the request with sequence number 1 to the 
application server business logic in the form of an XTPI message. 

3. The application server business logic sends the request to the T&S as an MTCP 
message. 

4. The T6S processes the transaction by sending the request to the FI. 

5. The FI sends the response to the TGS. 

6. The TGS sends the response to the application server business logic in the form of an 
MTCP response message. 

7. The application server business logic determines the next sequence number as 2. The 
response of the transaction along with the next sequence number is sent to the 
payment application in the web tier. 

8. The status of the transaction is set to pending persistent reversal. 

9. The response is displayed on the mobile device. 

10. Once the user of the mobile device attempts the next transaction, the payment 
application sends the user interface (WML deck) along with the sequence number 2 to 
the mobile device. 

11. A new transaction is sent from the device with sequence number 2 to the payment 
application. 

12. The payment application forwards the request with sequence number 2 to the 
application server business logic. 

13. The business logic determines that the request contains the next sequence number 
and sets the status of the previous transaction to completed. 

14. The next transaction is processed. 
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Scenario Two 

1. A request is sent from the WAP device with sequence number 1 and is received b^lhs 
payment application. 

2. The payment application forwards the request with sequence number 1 to the 
application server business logic in the form of an XTPI message. 

3. The application server business logic sends the request to the TGS as an MTCP 
message. 

4. The TGS processes the transaction by sending the request to the Fl. 

5. The Fl sends the response to the TGS. 

6. The TGS sends the response to the application server business logic in the form of an 
MTCP response message. 

7 The application server business logic determines the next sequence number as 2. The 
response of the transaction along with the next sequence number is sent to the 
payment application in the web tier. 

8. The status of the transaction is set to pending persistent reversal. 

9. The response cannot be displayed on the mobile device, as the message has been lost 
on the wireless downlink. 
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10. The user does not see the response and attempts to resend the transaction. Th 
transaction request is sent with sequence number 1 to the payment application. 

11. The payment application forwards the request with sequence number 1 to the 
application server business logic in the form of an XTPI message. 

12. The business logic determines an identical request has been received. Since the 
business logic retains the response for the previous transaction, the response is sent 
back to the payment application with sequence number 2. 

13. The response is received by the mobile device. 
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Scenario Three 

1. A request is sent from the WAP device with sequence number 1 and is received by the 
payment application. 

2. The payment application forwards the request with sequence number 1 to the 
application server business logic in the form of an XTPI message. 

3. The application server business logic sends the request to the T6S as an MTCP 
message. 

4. The TSS processes the transaction by sending the request to the FI. 

5. The FI sends the response to the TSS. 

6. The TSS sends the response to the application server business logic in the form of an 
MTCP response message. 
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7. The application server business logic determines the next sequence number as 2. The 
response of the transaction along with the next sequence number is sent to the 
payment application in the w b tier. 

8. The status of the transaction is set to pending persistent reversal. 

9. The response cannot be displayed on the mobile device, as the message has been lost 
on the wireless downlink. 

10. The user does not see the response and attempts to resend the transaction. 
However, the user chooses to change some of the fields before resubmitting the 
request. The modified transaction request is sent with sequence number 1 to the 
payment application. 

11. The payment application forwards the request with sequence number 1 to the 
application server business logic in the form of an XTPI message. 

12. The business logic determines a different transaction has been received with 
sequence number L In this case, the business logic determines that previous 
transaction has been lost and attempts to perform a reversal on the previous 
transaction. 

13. Once the reversal request has been processed successfully, the application server 
business logic sends the modified transaction request to the T6S as an MTCP 
message. 

14. The T6S processes the transaction by sending the request to the FI. 

15. The FI sends the response to the TGS. 

16. The TSS sends the response to the application server business logic in the form of an 
MTCP response message. 

17. The application server business logic determines the next sequence number as 2. The 
response of the transaction along with the next sequence number is sent to the 
payment application in the web tier. 

18. The status of the transaction is set to pending persistent reversal. 

19. The response is displayed on the mobile device. 
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